Event processing software may refer to software that processes events issued by computer systems and applications. Events may include but are not limited to system events and business events. A system event may refer to an event reporting important information regarding the state or performance of a computer system. For example, a system event may be sent when a particular server's processing load or memory utilization exceeds a certain threshold. A business event may refer to an event reporting business information. For example, a business event may notify the arrival of a purchase order. In another example, a business event may indicate the shortage of an item in a warehouse.
These events may be generated by what is referred to herein as “event producers.” Event producers, which may be software applications, may be configured to generate an event whose content is set according to criteria established by their configuration. For example, an application in an electronic cash register (“event producer”) may generate an event indicating that a certain number of units of a particular product was purchased (e.g., three quarts of milk). The criteria for setting the event content in this example corresponds to indicating that the number of units of a purchased produce should be reported.
The events generated by event producers may be received by what are referred to herein as “event consumers.” Event consumers, which may be software applications, may be configured to process an event issued by the event producer. For example, referring to the above example involving the cash register, the event indicating the number of units of the designated product that was purchased may be processed by an application (“event consumer”) that keeps track of the number of items for each product on the shelf in the store. The event consumer may process the event by reducing the shelf-inventory for the purchased product by the number of units reportedly purchased.
Each event consumer may be interested in only particular events generated by event producers. For example, referring to the above example involving the cash register, the event consumer may only be interested in events relating to the purchase of store items and not interested in events indicating technical error conditions or events related to the performance of a particular server. As a result, a “pre-filter” may be designed to allow only the events of interest to be sent to the event consumer associated with that pre-filter. Those events that are not of interest to the particular event consumer will be blocked in order to avoid event consumer overload due to “bombardment” with irrelevant events. For example, referring to the above example involving the cash register, a pre-filter may be designed to only allow those events relating to the purchase of store items to be transmitted to the event consumer. The events of interest transmitted to an event consumer are often first routed to a queue, from which they are read and processed by the event consumer in their sequence of arrival.
Event consumers declare which events are of interest to them by using what is commonly referred to as “event subscriptions.” Event subscriptions may be formulated as Boolean conditions based on event content. Typically, event subscriptions first test for the event type, from which one may determine the event's structure, and then may test the content of specific fields. For example, an event subscription for events from cash registers that report the purchase of produce items may contain the following expression: eventType=‘purchaseEvent’ and productCategory=‘produce.’ A single event consumer may have several event subscriptions to define the events of interest for the event consumer.
As discussed above, pre-filters may be designed to block events that are not of interest to the event consumer. Pre-filters can be constructed by using criteria derived from the event consumer's event subscriptions. Typically, the more conditions the pre-filter uses to filter out the events not of interest to the event consumer (for example in a pre-filter for purchase order events: the customer has “gold” status; the value of the order is $1,000 or greater; and the order is marked “urgent” indicating that customer desires fast shipment), the greater the efficiency of the pre-filter in distributing only those events of interest to the queue. However, the more complex of the design of the pre-filter (i.e., the more conditions a pre-filter uses to filter out events not of interest), the longer it will take to evaluate it in distributing those events to the queue thereby possibly starving the event consumer. Hence, there is an inverse relationship between pre-filter efficiency (precision in discriminating events) and pre-filter throughput.
Currently, there are no means for achieving a balance between pre-filter efficiency and pre-filter throughput thereby optimizing overall performance in distributing events to event consumers and processing them.
Therefore, there is a need in the art to develop a means for achieving a balance between pre-filter efficiency and pre-filter throughput thereby optimizing overall performance in distributing events to event consumers and processing them.